Sécurité de Docker

Ajouter des liens
Un article de Wikipédia, l'encyclopédie libre.
Article principal : Docker (logiciel).

La sécurité de Docker est relative aux menaces et attaques qui remettraient en question la sécurité informatique basée sur les services de confidentialité, d’intégrité et de disponibilité. L'article traite des différents types d'attaques, des risques et des solutions apportées afin de sécuriser Docker.

Sécurité des données[modifier | modifier le code]

Article détaillé : Sécurité des systèmes d'information.

La sécurité informatique consiste à garantir que les ressources matérielles ou logicielles d'une organisation sont uniquement utilisées dans le cadre prévu[1].

Confidentialité[modifier | modifier le code]

Seules les personnes autorisées peuvent avoir accès aux informations qui leur sont destinées. Tout accès indésirable doit être empêché. Les seules utilisateurs pouvant accéder au daemon docker sont les personnes faisant partie du groupe Docker ou les administrateurs de la machines, ce qui empêche en théorie une utilisation indésirable[2],[3].

Intégrité[modifier | modifier le code]

Les données doivent être celles que l'on attend, et ne doivent pas être altérées de façon fortuite, illicite ou malveillante. En clair, les éléments considérés doivent être exacts et complets. Dans docker l'intégrité vient de la confiance, c'est-à-dire que l'utilisateur décide de récupérer une image docker sur le hub de docker qui est un ensemble d'images communautaires[4]. Afin d'être sûr du choix d'image, docker a mis en place un système de certification qui garantit une image de qualité et non malveillante[5].

Disponibilité[modifier | modifier le code]

Le système doit fonctionner sans faille durant les plages d'utilisation prévues et garantir l'accès aux services et ressources installées avec le temps de réponse attendu. De base docker fournit une fonctionnalité afin d'avoir de la haute disponibilité, Docker Swarm, un orchestrateur qui permet de gérer son cluster de conteneurs[6]. Il existe un autre orchestrateur qui est beaucoup plus performant et domine le marché : Kubernetes[7].

Attaques[modifier | modifier le code]

Différentes attaques docker

Docker est la cible d'attaques depuis sa création, on peut distinguer trois sources d'attaques, le conteneur (en)Docker, la machine hôte, et le réseau. De plus, le niveau de risque est affecté par la façon dont l’utilisateur interagit avec Docker[8].

Par le conteneur[modifier | modifier le code]

Les attaques par le conteneur (en) sont la source principale d'attaques. En effet, une étude réalisée sur 356 216 images a montré qu'en moyenne, il y a 180 vulnérabilités sur les images officielles ainsi que les non officielles[9]. De plus, une grande partie des images présentes sur les recueils d'images ne sont jamais supprimées ou mise à jour. Les anciennes images peuvent toujours être téléchargées, mais la plupart n'ont pas été mise à jour depuis une centaine de jours et introduit plusieurs vulnérabilités[10].

Une attaque par le conteneur est principalement conduite par l'application présente dans l'image. Les conteneurs Linux n'ont pas été conçus comme un mécanisme de sécurité permettant d'isoler les conteneurs non fiables et potentiellement malveillants[11]. De plus, les conteneurs sont beaucoup plus sensibles aux attaques en comparaison aux machines virtuelles, qui doivent contourner le noyau de l'ordinateur virtuel et l'hyperviseur avant d'attaquer le noyau hôte[12],[13].

Les conteneurs compromis sont également susceptible de compromettre le bon fonctionnement des autres conteneurs présents sur la même machine hôte. De ce fait, une application détournée pouvant obtenir des droits privilégiées du noyau, est susceptible de compromettre tous les conteneurs en cours d'exécution ainsi que la plate-forme hôte[14].

Par la machine hôte[modifier | modifier le code]

Étant donné que les conteneurs (en) fonctionnent sur le même noyau de l'hôte, ils sont vulnérables aux exploits du noyau. Un exploit donnant des privilèges root complets à un conteneur peut permettre à un attaquant de percer ce conteneur et de compromettre l'hôte[15].

Docker est basé sur la bibliothèque libcontainer[16], cependant cette bibliothèque possède plusieurs failles d'isolations : l'évasion de chroot, la traversée de répertoire, l'accès au système de fichier de l'hôte, l'élévation de privilège ainsi que l'élévation de container. Depuis que les processus des conteneurs sont souvent utilisés avec le PID 0, ils ont la possibilité de lire et d'écrire sur le système de fichier. Ils sont même autorisés à écraser les binaires de l'hôte et de les remplacer par celui de l'attaquant, l'exécution de code arbitraire avec les privilèges root sont donc possibles[15],[17].

Par le réseau[modifier | modifier le code]

Par défaut, la connectivité entre les conteneurs (en) et la machine hôte est fournie via un pont ethernet virtuel[18]. Les attaques par ARP poisoning et saturation de la table d'apprentissage entre conteneurs sur le même hôte est donc possible[12],[18].

Le démon Docker est contrôlé à distance via une socket appartenant à root:docker. L'accès à cette socket permet aux attaquants d'extraire et d'exécuter n'importe quel conteneur en mode privilégié, leur donnant ainsi un accès root à l'hôte[19]. À partir d'un système d'exploitation hôte compromis, les attaquants peuvent analyser, bloquer, injecter ou rediriger les communications réseau et système[20],[21]. L'attaquant peut effectuer diverses attaques telles que le déni de service et l'élévation des privilèges[12].

La distribution d'images par le biais du Docker Hub et d'autres registres de l'écosystème Docker est une source de vulnérabilités. Parce que ces vulnérabilités sont similaires aux gestionnaires de paquets classiques[22]. Le traitement, le stockage et la décompression du code potentiellement non fiable, sont effectués par le démon Docker avec les privilèges root[23],[24].

Risques[modifier | modifier le code]

Risques d'extensions d'attaque Docker

Depuis le lancement de docker, plusieurs mises à jour et modifications ont été apportées pour améliorer sa sécurité, cependant les risques sont toujours présents. Selon une CVE les risques de docker sont l'exécution de code, l'accès à une ressource non désirée, le gain de privilège, le gain d'information et le déni de service[25].

Extension de l'attaque[modifier | modifier le code]

Si un conteneur (en) a été attaqué, il y a de grandes chances que l'attaque s'étende jusqu'à l'hôte. Cela peut compromettre le système tout entier en sortant du conteneur et en obtenant les droits d'administrateur. L'attaquant pourra alors exécuter du code et propager l'attaque aux autres composants du même réseau. Ces attaques sont conduites via les exploits du kernel ou par les ressources partagées entre les conteneurs et l'hôte (système de fichiers, mémoire, réseaux et volumes)[22],[26].

Répercussion sur les autres services[modifier | modifier le code]

Dans une architecture basée sur les conteneurs (en), ils partagent tous les mêmes ressources kernel. Il y a une condition de déni de service qui se crée si un conteneur est exploité, les autres seront impactés[27].

Contre mesures[modifier | modifier le code]

La seule solution afin d'améliorer la sécurité de docker est de se prévenir des différents types d'attaques. Afin de s'en protéger un minimum, des bonnes pratiques sont à utiliser ainsi que choisir du contenu de confiance. Il existe néanmoins certains outils améliorant la sécurité comme SElinux, Apparmor et les Cgroups.

Bonnes pratiques[modifier | modifier le code]

Adopter de bonnes pratiques est une façon simple d'augmenter la sécurité d'une infrastructure docker. La meilleure protection des systèmes en termes d'isolation est celui qui ne partage aucune ressource physique avec les autres. La protection physique est souvent le meilleur moyen de se protéger des attaques. C'est-à-dire si le conteneur ne nécessite pas d'accès, il ne faut pas lui en donner[28].

Une autre façon de sécuriser des conteneurs (en) Docker est de limiter le mode privilégié à certains conteneurs. Les conteneurs Docker sont assez sûrs si nous prenons assez de précautions pour exécuter des charges de travail à l'intérieur des conteneurs en mode non privilégié[29]. De ce fait, seuls les utilisateurs de confiance doivent être autorisés à contrôler le démon Docker[30].

Les conteneurs partagent le même noyau que la machine hôte, les noyaux n'étant plus mis à jour sont plus enclins à être exposés à des vulnérabilités publiques. Mettre régulièrement à jour le noyau avec les outils proposés par le système d'exploitation permet de réduire ce risque[31].

Contenu de confiance[modifier | modifier le code]

Une des possibilités afin de limiter les risques d'attaques est d'utiliser seulement du contenu de confiance. Docker propose d'utiliser des images certifiées, c'est-à-dire que nous sommes sûr que ces images sont fiables et possèdent seulement le contenu qu'elles proposent. Afin d'être certifiée, une image doit passer une série de tests sur l'API de docker grâce à l'outil inspectDockerImage fourni par docker[5]. Il existe aussi des images avec des étiquettes spéciales "éditeur vérifié" et "image officielle", cela ne garantit pas la qualité de l'image mais au moins la provenance d'un éditeur reconnu[32],[33]. Docker propose une option afin d'utiliser seulement les images de confiances : 

$ export DOCKER_CONTENT_TRUST=1

Le versionnage de l'image est aussi un facteur important, quand une image est envoyée sur le Docker Hub on peut lui préciser une version. Il est souvent préférable de choisir de récupérer une version connue et stable, par défaut, la dernière version est choisie pour le téléchargement de l'image[34],[35].

Au sein d'une entreprise, l'utilisation de docker avec une registry privée est recommandée. Une registry Docker est une application serveur de type conteneur qui permet de stocker et distribuer des images Docker avec un système d'authentification. Cela permet de limiter l'accès de nos conteneurs (en) internes, qu'ils ne se retrouvent pas sur le hub docker à la vue de tous[34],[36].

SELinux[modifier | modifier le code]

Article détaillé : SELinux.

SELinux permet de définir une politique de contrôle d'accès obligatoire aux éléments d'un système. Docker utilise trois politiques de fortification de SELinux : le mécanisme de Type renforcement (en), sécurité multi-catégories (en) et la sécurité multi-niveau[37]. Docker attribue une étiquette SELinux avec un ensemble réduit de privilèges à tous les processus exécutés dans les conteneurs (en). Le type renforcement est utilisé pour protéger le moteur Docker et l'hôte des conteneurs, qui peuvent provenir de sources non fiables[38]. La méthode d'accès de contrôle de sécurité multi-catégories protège un conteneur des autres conteneur ayant le même type de renforcement[39]. Actuellement, tous les conteneurs s'exécutent avec le même type SELinux, svirt_lxc_net_t, tel que défini dans le fichier de configuration de règles lxc_contexts[38]. Ces conteneurs ne sont donc pas isolés les uns des autres[40].

L'application des étiquettes SELinux se fait avec le paramètre --security-opt au lancement du conteneur. 

$ docker run -d --security-opt label=type:docker_apache_t httpd

Les éditeurs publient leur politique SELinux liée à leurs images sur la plate-forme hôte. Les politiques sont déclarées dans le Dockerfile et sont placées dans les métadonnées de l'image au moment de sa construction[41].

AppArmor[modifier | modifier le code]

Article détaillé : AppArmor.

AppArmor est également un modèle d’amélioration de la sécurité pour Linux basé sur le contrôle d’accès obligatoire, comme SELinux, mais en limitant aux programmes individuels. Docker supprime les capacités du système et fait des restrictions sur les points de montage. Le contrôle d’accès obligatoire peut imposer des contraintes si le flux d’exécution normal n’est pas respecté[42]. Par défaut, Docker autorise les accès complet au réseau et au système de fichier avec toutes les capacités système[43].

Cgroups[modifier | modifier le code]

Article détaillé : Cgroups.

Les Cgroups, ou groupes de contrôles offrent la possibilité de calculer et de limiter les ressources utilisées par les conteneurs (en). De ce fait, les Cgroups offrent la possibilité de limiter les attaques par déni de service en limitant les ressources système[31].

Les Cgroups sont un composant clé qui permet à docker de réguler le nombre de ressources utilisées, comme l'utilisation du CPU, de la mémoire, des entrées et sorties disques pour chaque conteneur. En s'assurant que chaque conteneur obtient une part équitable de ressources et qu'un conteneur ne consomme pas toutes celles disponibles. Ils permettent également à docker de déterminer les limites et les contraintes liées aux ressources allouées à chaque conteneur. Par exemple, une telle contrainte est de limiter le nombre de cœurs CPU disponibles à un conteneur spécifique[2],[31],[39].

Références[modifier | modifier le code]

  1. ↑ Pillou 2006, p. 36
  2. ↑ a et b Amith 2016, p. 95
  3. ↑ Combe 2016, p. 58
  4. ↑ Docker
  5. ↑ a et b Docker Certified
  6. ↑ Docker Swarm
  7. ↑ Kubernetes
  8. ↑ failles de sécurité
  9. ↑ Martin 2018, p. 33
  10. ↑ Martin 2018, p. 37
  11. ↑ Mattetti 2015, p. 559
  12. ↑ a b et c Chelladhurai 2016, p. 856
  13. ↑ Loukidis-Andreou 2018, p. 1561
  14. ↑ Yasrab 2018, p. 3
  15. ↑ a et b Martin 2018, p. 41
  16. ↑ Marmol 2016, p. 2
  17. ↑ Bui 2015, p. 3
  18. ↑ a et b Bui 2015, p. 4
  19. ↑ Combe 2016, p. 57
  20. ↑ Martin 2018, p. 38
  21. ↑ Combe 2016, p. 59
  22. ↑ a et b Combe 2016, p. 60
  23. ↑ Martin 2018, p. 39
  24. ↑ CVE-2014-9357
  25. ↑ CVE stat docker
  26. ↑ Mattetti 2015, p. 560
  27. ↑ Yasrab 2018, p. 4
  28. ↑ Shu 2016, p. 10
  29. ↑ Chelladhurai 2016, p. 857
  30. ↑ Vulnerability exploitation in Docker container environments
  31. ↑ a b et c Yasrab 2018, p. 8
  32. ↑ Docker publisher
  33. ↑ Amith 2016, p. 96
  34. ↑ a et b Docker registry
  35. ↑ Docker security
  36. ↑ Docker registry
  37. ↑ Bui 2015, p. 5
  38. ↑ a et b Bacis 2015, p. 749
  39. ↑ a et b Bui 2015, p. 6
  40. ↑ Martin 2018, p. 32
  41. ↑ Yasrab 2018, p. 6
  42. ↑ 2018 Martin, p. 41
  43. ↑ 2016 Combe, p. 58

Bibliographie[modifier | modifier le code]

  • JF Pillou, Tout sur les systèmes d’information, 3e édition, Dunod, , 262 p. (ISBN 978-2-10-058800-8 et 2-10-058800-1)Document utilisé pour la rédaction de l’article
  • Julien Raéis et Matthieu Buffet, « Audit de sécurité d’un environnement Docker », (consulté le ), p. 1–44
  • (en) Stephen Smalley, Chris Vance et Wayne Salamon, Implementing SELinux as a Linux Security Module
  • (en) Theo Combe, Antony Martin et Roberto Di Pietro, « To Docker or Not to Docker: A Security Perspective », Cloud Computing, IEEE, vol. 3, no 5,‎ , p. 54–62 (ISSN 2325-6095, DOI 10.1109/MCC.2016.100)Document utilisé pour la rédaction de l’article
  • (en) Victor Marmol, Rohit Jnagal et Tim Hockin, Networking in Containers and Container Clusters, Document utilisé pour la rédaction de l’article
  • (en) Fotis Loukidis-Andreou, Ioannis Giannakopoulos, Katerina Doka et Nectarios Koziris « Docker-Sec: A Fully Automated Container Security Enhancement Mechanism » () (DOI 10.1109/ICDCS.2018.00169)
    — « (ibid.) », dans Distributed Computing Systems (ICDCS), 2018 IEEE 38th International Conference on, vol. 2018-, IEEE (ISBN 978-1-5386-6871-9), p. 1561–1564    Document utilisé pour la rédaction de l’article
  • (en) G. Perrone et S. P. Romano « The Docker Security Playground: A hands-on approach to the study of network security » () (DOI 10.1109/IPTCOMM.2017.8169747)
    — « (ibid.) », dans 2017 Principles, Systems and Applications of IP Telecommunications (IPTComm), p. 1–8
  • (en) Thanh Bui, « Analysis of Docker Security », CoRR, vol. abs/1501.02967,‎ Document utilisé pour la rédaction de l’article
  • (en) Rui Shu, Peipei Wang, Sigmund A Gorski III, Benjamin Andow, Adwait Nadkarni, Luke Deshotels, Jason Gionta, William Enck et Xiaohui Gu, « A Study of Security Isolation Techniques », ACM Computing Surveys (CSUR), vol. 49, no 3,‎ , p. 1–37 (ISSN 1557-7341, DOI 10.1145/2988545)Document utilisé pour la rédaction de l’article
  • (en) Ashok Amith Raj MP, Sahithya J Kumar, Ashika Pai et Ashika Gopal « Enhancing security of Docker using Linux hardening techniques » () (DOI 10.1109/ICATCCT.2016.7911971)
    — « (ibid.) », dans Applied and Theoretical Computing and Communication Technology (iCATccT), 2016 2nd International Conference on, IEEE (ISBN 978-1-5090-2399-8), p. 94–99    Document utilisé pour la rédaction de l’article
  • (en) Deploying Secure Containers for Training and Development, , 64 p. (ISBN 978-0-12-804717-0, lire en ligne)
  • (en) Enrico Bacis, Simone Mutti, Steven Capelli et Stefano Paraboschi « DockerPolicyModules: Mandatory Access Control for Docker containers » () (DOI 10.1109/CNS.2015.7346917)
    — « (ibid.) », dans Communications and Network Security (CNS), 2015 IEEE Conference on, IEEE (ISBN 978-1-4673-7876-5), p. 749–750    Document utilisé pour la rédaction de l’article
  • (en) Yang Luo, Wu Luo, Xiaoning Sun, Qingni Shen, Anbang Ruan et Zhonghai Wu « Whispers between the Containers: High-Capacity Covert Channel Attacks in Docker » () (DOI 10.1109/TrustCom.2016.0119)
    — « (ibid.) », dans Trustcom/BigDataSE/ISPA, 2016 IEEE, IEEE (ISBN 978-1-5090-3205-1), p. 630–637
  • (en) A. Martin, S. Raponi, T. Combe et R. Di Pietro, « Docker ecosystem – Vulnerability Analysis », Computer Communications, vol. 122,‎ , p. 30–43 (ISSN 0140-3664)Document utilisé pour la rédaction de l’article
  • (en) Jeeva Chelladhurai, Pethuru Raj Chelliah et Sathish Alampalayam Kumar « Securing Docker Containers from Denial of Service (DoS) Attacks » () (DOI 10.1109/SCC.2016.123)
    — « (ibid.) », dans Services Computing (SCC), 2016 IEEE International Conference on, IEEE (ISBN 978-1-5090-2628-9), p. 856–859    Document utilisé pour la rédaction de l’article
  • (en) Robail Yasrab, « Mitigating Docker Security Issues », CoRR, vol. abs/1804.05039,‎ Document utilisé pour la rédaction de l’article
  • (en) A R Manu, Jitendra Kumar Patel, Shakil Akhtar, V K Agrawal et K N Bala Subramanya Murthy « Docker container security via heuristics-based multilateral security-conceptual and pragmatic study » () (DOI 10.1109/ICCPCT.2016.7530217)
    — « (ibid.) », dans Circuit, Power and Computing Technologies (ICCPCT), 2016 International Conference on, IEEE (ISBN 978-1-5090-1277-0), p. 1–14
  • (en) M. Mattetti, A. Shulman-Peleg, Y. Allouche, A. Corradi, S. Dolev et L. Foschini « Securing the infrastructure and the workloads of linux containers » () (DOI 10.1109/CNS.2015.7346869)
    — « (ibid.) », dans 2015 IEEE Conference on Communications and Network Security (CNS), p. 559–567    Document utilisé pour la rédaction de l’article
  • (en) L. Bass, R. Holz, P. Rimba, A. B. Tran et L. Zhu « Securing a Deployment Pipeline » () (DOI 10.1109/RELENG.2015.11)
    — « (ibid.) », dans 2015 IEEE/ACM 3rd International Workshop on Release Engineering, p. 4–7

Liens externes[modifier | modifier le code]

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Sécurité_de_Docker&oldid=212413444 ».